Forum PHP.pl

A nie da rady zrobić indeksy dla obydwu protokołów??Pewnie więcej byłoby z tym pracy ,ale myślę że by się opłacało ,bo w przyszłości mamy problem z głowy.

Więc tak - zależy o jaką bazę danych się rozchodzi. Czy jest to Mysql, Postgresql czy Oracle itp..

Problem polega na tym że adres ipv4 można zapisać jako 32bitowego inta, który się bardzo dobrze indeksuje i można dużo szybciej wyszukać dany rekord. Sama baza danych posiada wbudowane mechanizmy do przekształcania tego inta na adres ipv4. Oczywiście można również dać varchar i też go indeksować, ale jego wydajność będzie zawsze niższa. Przy ipv6 potrzeba 128 bitów, największa jednostka (Mysql) to bigint, który ma 64 bity, także do tego zadania potrzeba dwóch kolumn. Wówczas sprawa się znacznie komplikuje. I naturalnym jest poszukiwanie innego typu kolumny. Jakikolwiek by to nie był typ kolumny będzie zawsze słabszy w porównaniu do 32bitowego inta. Sam ipv6 będzie zawsze słabszy(wolniejszy) nie ważne jaką metodę się zastosuje - bo jest znacznie dłuższy.

Pytanie jest takie - czy ja dzisiaj będę w stanie zaprojektować lepszy system do przeszukiwania i przechowywania ipv6 od konstruktorów baz danych (mimo tego że przez wiele lat będzie on w ogóle nie wykorzystany) ? Oczywiście że nie. To tak samo jakbyś przerabiał auto na gaz. No jakoś leci i pracuje. A jaki będzie wynik jak konstruktor silnika będzie go specjalnie projektował pod gaz. Wynik na pewno będzie lepszy. Problem ipv6 jest odległym tematem. W poprzednich postach próbowałem wytłumaczyć dlaczego tak opornie to idzie, że mamy taki stan rzeczy. Dzisiaj nie powinno się go jeszcze stosować, ponieważ za 10 lat nie ważne jak dobry kawał roboty byś zrobił - twoja stronka czy aplikacja i tak będzie wymagała renowacji. Weźmy na tapetę znowu przykład samochodów. Czy jakikolwiek samochód wyprodukowany 10 lat temu jest lepszy od produkowanych dziś (pomijając sentymenty (IMG:style_emoticons/default/wink.gif) ) ? No jest to tak oczywiste, że nie wymaga dodatkowych objaśnień.

Dzisiaj bazy danych nie posiadają tych dobrych mechanizmów, a wynika to z tego że ich nie ciśnie po prostu, a jest dużo innych ważnych rzeczy do zrobienia.

Zawsze moszna przechowywać w kolumnie binary-te adresy.Przed zapisem konwertować sttringa do binary,do odczytu konwertować binary do stringa.Możnaby użyć do tego serializacji.Myśle że problemu by z tym nie było, tylko jak z indeksowaniem kolumny binary??

Da się binary jak varbinary i indeksują się również. Tylko podejrzewam że z wydajnością nie jest super. Sposobów na zapis ipv6 jest wiele w necie. Można sobie wybrać jakiś konkretny i sobie zastosować pamiętając o tym że ipv4 też musi tam wleźć i jakoś trzeba to sprawdzić i rozróżnić.

Z wydajnością nie będzie problemów. Właściwie jedyną przewagą indeksu kolumny typu INTEGER jest fakt, że w pewnych przypadkach pobierając dane można wyciągnąć je bezpośrednio z indeksu (nie angażując w ogóle dysku do odczytu danych).

IPv4 można zapisać w formie IPv6 i dosyć łatwo rozpoznać później czy dany IPv6 jest w praktyce v4.

Z tego co wiem tabela musi być w pamięci, jeżeli z dysku nie odczytuje . Nie kumam tego w ogóle. Przybliż mi proszę co miałeś na myśli, bo zaciekawiłeś mnie tym postem;)

W pewnych przypadkach, możliwe jest odczytanie danych bezpośrednio z indeksu, który to jest w pamięci, bez wykorzystywania dysku. By do czegoś takiego doszło muszą być spełnione dwa podstawowe warunki:
1. Indeks musi być równy danym, które reprezentuje, a to w przypadku liczb całkowitych (INT) jest spełnione. Przykładowo: index(0x1455E7) = 0x1455E7 - OK, index("Ala ma kota") = 0x34A35933 - nie OK.
2. Zapytanie musi korzystać wyłącznie z kolumn występujących w indeksie.

I tak zapytanie:

[SQL] pobierz, plaintext 
SELECT ip FROM tbl_name WHERE ip BETWEEN INET_ATON("145.77.42.0") AND INET_ATON("145.77.42.255")
[SQL] pobierz, plaintext 

Ma możliwość pobrania wszystkiego bezpośrednio z indeksu, bez angażowania dysku.

Jak znajdę kiedyś chwilę to wezmę to na warsztat do sprawdzenia;)